Resource Library: Multimedia/Resource Library: Multimedia.iso/utils/graphic/convrtrs/mac/sprkl103.hqx/README 1st

Text File | 1993-05-12 | 10.1 KB | 190 lines

Sparkle: A new mac MPEG player.
-------------------------------

Hi there, friendly users. This is release 1.02 of my mac MPEG player.
One day a few weeks ago it struck me as ridiculous that no mac MPEG
player existed---how hard could it be to write one? So I grabbed the
Berkeley UNIX source for an X-windows based MPEG player and managed to
get it compiled and running on my mac in a few hours. But the result was
very unsatisfactory, a completely un-mac-like application. So I spent
some time integrating what I had into the framework of the Think Class
Library and this is the result.
(Anyone who wants to play with the Berkeley code can get it from
toe.cs.berkeley.edu in pub/multimedia/mpeg.)

Please read all of this document before playing with the program. While
actually using the program is pretty simple, there are a few things you
should be aware of.

Features:
Ñ    Standard mac interface with menus and windows.
Ñ    Uses the QuickTime movie controller to control the MPEG viewing.
Ñ    MultiFinder friendly, with good backgrounding behavior.
Ñ    Saves MPEGs to QuickTime movies.
Ñ    Can open multiple files at once.
Ñ    Free.

To run it needs at least:
Ñ    System 7.
Ñ    QuickTime 1.5
Ñ    A 68020 or better.
Ñ    2MB to play one 160x120 MPEG---to open more or large MPEGs increase the
    partition.

This program works fine, with good handling of errors, on my SE/30, but
that's the only machine I have to test it. If you find a bug that is not
caused by the various things listed below, please mail me with as many
details as possible, both about your machine and about what the  program
was last doing before it died on you.

I don't think there's much to say on the use of this program---you pretty
much run it like any other mac program. The one important thing to note
is that I don't yet know what whoever it is who decides these things has
said the file type of MPEG files should be. Thus Sparkle will open files
of type 'MPEG', type 'BINA' and type '????'. It WILL NOT open files of
type 'TEXT'. I know this is the file type used by the other mac (but not
very mac-like) MPEG program out there, and I considered adding it, but if
one is using something like Boomerang it makes the menus a pain. If
anyone desperately needs this feature, mail me with a justification and I
might add it. To get a custom icon, give the MPEG file a type of 'MPEG'
and a creator of 'mMPG'.

There are a number of limitations to this release of the program and I
want to explain them so that people don't get angry at me for a lousy
piece of code, or tell me how any bozo could do better. The program
should work fine if you don't stress it too hard. If you don't like
these limitations, you are welcome to trash it and wait for version 2.0
which will (I hope) remove them. I figured people would prefer a usable,
non-perfect program to nothing.

The limitations stem from two sources. One is that I do NOT have a copy
of the MPEG Draft International Standard, the document that details the
exact nature of the MPEG file format---how many bits in each field, what
different fields do etc. All I have is the Berkeley MPEG code, and an
overall understanding of how MPEG encoding works. I have a copy of the DIS
on order, but until I have it in my hands, I am limited in what I can do.
The Berkeley MPEG code has problems. It sometimes skips frames. It
produces random fuzz around the edge of pictures. Sometimes it creates a
block of the wrong color. Also the Berkeley code was written for a UNIX
box, thus it assumes infinite memory reserves and guzzles them happily.
It assumes 32 bit ints. It may assume multiplications are cheap.

I have started working on making the Berkeley code more mac
friendly---attempting to use 16 bits ints where possible, attempting to
speed up the code, making the Berkeley subroutines object methods---but
I have hit the limit of what I can do without the DIS. This program
suffers from various anomalies because of that UNIX heritage:
Ñ    Errors in the UNIX code are not well handled---they may pop up an
    informational message or they may crash the machine.
Ñ    Memory handling in the UNIX code is poor. Lots of memory is allocated
    in a very un-mac-friendly way. If the system runs out of memory while in
    the UNIX code it may (rarely) crash or (more likely) stop what it's
    doing without an error message.
Ñ    Frames may occasionally be skipped, particularly at the beginning of
    the movie.
Ñ    The total number of frames given for the movie when it plays is an
    estimate. Because of skipped frames and other features, the movie may
    stop playing a few frames before that number is reached---for example
    the movie may stop playing at what it says is frame 295/300.
Ñ    Random access on movies is not supported---you can go forward, and
    rewind to the start---that's it.
Ñ    Displaying frames is slow---I get about a frame per two seconds on my
    SE/30 on a 120x160 MPEG. It's not really practical to attempt to view
    the movie this way---convert it to QuickTime and watch that.
Ñ    Towards the beginning of the movie (in the first two or three frames)
    if you force an update event on a window, it will display garbage.
I hope to fix all these problems, but I'm not going to waste time trying
to code around them until I get the DIS.

The portion of the code written by me, the user interface elements,
should behave much better. If any problems occur within that code you
should get an error message and things should continue smoothly.

I appreciate that most of you won't care whether a problem is in my code
or the UNIX code---you want bug-free software. I'm explaining this so you
see why I can't yet give that to you.

I have a number of ideas to add to this code, but wanted to release
something before summer. My summer plans are unsettled, but I may have
a job far from any mac, so it may be some time before version 2.0 comes
out. I have many plans and ideas for this program---they'll be added
pretty much randomly as the mood strikes me. You're welcome to suggest
ideas, but I've probably already thought of them.
Among others:
Ñ    Balloon help.
Ñ    Scriptability.
Ñ    Displaying the QT movie as it's made so you can see if you like the
    quality and frame-rate.
Ñ    Connecting to PhotoShop (or at least PhotoShop plugins) to fiddle each
    frame before saving it---some MPEGs are way too blurry.
Ñ    Adding an "About box..." (It was either that or GWorld support as the
    last thing I did before release and I figured GWorld support was more
    important.)
Ñ    Improve the message displaying.
Ñ    Add animated cursors during the lengthy startup periods.
Ñ    User preferences for various things.

If people can help with the following, I would be grateful:
Ñ    My present icons aren't great (IMHO) (though are better than some I've
    seen. If anyone comes up with something better and wants to donate them
    to me, I'll gladly accept.)
Ñ    Are any of my command-keys or menu outlays or such in violation of
    Apple Human Interface Guidelines? Any strong opinions on the matter
    welcomed.
Ñ    What sort of user interface should I present when playing back the
    QuickTime movie as it's being created from the MPEG? A separate window?
    A movie below the MPEG? Alongside the MPEG?
    And is possible to play a movie as it is being created? Anyone have any
    sample code that does this?
Ñ    How (in the context of the Think Class Library) do I get the number of
    document windows on the screen (ignoring the floating window and dialogs
    and such.) Right now I use
        gDesktop->itsWindows->GetNumItems()
    which sorta works but gives strange results I've had to compensate for
    as best I can (like when a single open document is being closed, it
    reports that two windows are open.) That call also falls apart when a
    CATCH handler is invoked as a result of low memory.
Ñ    What's the deal with G-worlds and dithering? Each MPEG frame is created
    by the reverse DCTs and other MPEG magic into a 24bit buffer which I set
    to the base address of a pixMap. If I directly copy-bits from that to
    the screen with a ditherCopy mode, at 8 bits or less I will get obvious
    tearing which looks ugly. So I created a GWorld with pixel depth 0, I
    copy-bits to the Gworld, then copy-bits from that to the screen. Each
    time through the loop, I use UpdateGWorld in case the screen depth has
    changed or the window has moved to a different monitor. So far so good.
    But, my first attempt to create a GWorld used the noNewDevice flag,
    which I figured was fine since I was using pixel-depth 0. However, if I
    dragged the window from my color screen to the SE/30's internal B/W
    screen then back to the color screen, strange things happened. My window
    contents were drawn fine, but the window title-bar and frame were mucked
    up. So I now create the GWorld without the noNewDevice flag, and the
    window is mostly fine, but if I drag it fully onto the B/W screen it
    give very strange dithering. If it partly straddles a color and B/W
    screen the dithering is fine.
    Why did my first GWorld call go wrong, and why is my dithering now wrong?
    I left things the way they are since it seemed more folks cared about
    tearing than about movie the window from one screen to another, but this
    bugs me.

Various people over the net helped me in the course of this project,
mailing me sample code or header files, answering questions etc. I won't
embarrass them by naming them, but will thank them here.
Also thanks to the author of the Infinity Windoid WDEF which I use in my
code.

I hope you like the name Sparkle. I can't believe no commercial software
uses it yet. It's based on a favorite phrase of a close friend of mine.

A thumbs down to the MPEG committee who won't put the MPEG specs up for
FTP anywhere, and make my life more difficult.
Another thumbs down for Apple who took forever to release the Inside
Mac: QuickTime volume and who STILL have not released the QuickTime
Components volume, and who don't yet have QuickTime 1.5 headers and glue
at their ftp site, let along QuickTime 1.6.
A thumbs up for Thinks C (not for Symantec as a whole---some of their
products suck). I do wish it were full C++, but their C+-, TCL and
debugger make for a really pleasnt environment.

Maynard Handley
[e-mail]
May 09 1993